home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / T0310 / text0035.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  4.9 KB  |  137 lines
  1. Frederic JAUME wrote:
  2.  
  3. > here's just a first try, tell me what you think.
  4.  
  5. Here goes then... :)
  6.  
  7. > There are a lot of question in the following document, so please
  8. > answer them!
  9. > 
  10. > Part one : the monsters and other things...
  11. > First, we need to choose a data structure, and then to create the AI.
  12. > thhen I 'll  explain the method that can be used for the monsters movements.
  13. > This method works! It's not very complex for the moment, but it's been used
  14. > in a game (that was done by a friend of mine) on amiga, some sort of Zelda/Ultima
  15. > adventure game that had to deal with monsters AI. Though, it was programmed in AMOS,
  16. > and neither my friend nor i, can code in 68030, so you'll just find algorithms, and
  17. > simple C code. Bad Mood deserves a more complex AI, but it's just
  18. > a beginning.
  19.  
  20. Fine. I'm sure we have enough assembler coders to be able to convert any algorithms
  21. you come up with...
  22.  
  23. >                 --------------------------------
  24. > 
  25. > An inportant part of the AI is the data structures to be used.
  26. > 
  27. > DATA STRUCTURES
  28.  
  29. Sounds fine to me...
  30.  
  31. > >>? Should we use the same sector numbering as the one used to build up
  32. >   levels, since there are a lot of them, and some of them will not have
  33. >   'things' inside (the small ones).
  34.  
  35. Dunno, but as the monsters can move, you cannot gaurentee that there will
  36. nothing in any sector...
  37.  
  38. > THE AI - 'INVISIBLE FOOTPRINTS' METHOD
  39. > 
  40. > - how does it work ?
  41. > to simulate a realistic chase, we can use the "invisible footprints/trail"
  42. > method, which is the following one:
  43. > we've got an array of that type:
  44.  
  45. Sounds like a good idea... 
  46.  
  47. > an interesting point is that, with this method we can have an intelligence
  48. > factor for each monster, which is in fact the ability of the monster to
  49. > see a particular amount of footprints (dumb monsters won't see any, so if
  50. > you just hide behind a wall, the dumb monsters think you disapeared, and
  51. > go back to watch BayWatch...
  52.  
  53. :-) Yes, this could be good... one point - if a monster had a very 'high'
  54. intelligence factor, it might see lots of trails from where you were ages
  55. ago - for it to be fairly intelegent it would also need to know which of
  56. the trails is the most recent.
  57.  
  58. Also, here is another form of the same problem.
  59.  
  60.      | m |
  61.      |   |
  62.      |   |  | pe |
  63. ------   ---/ "  /
  64. p ->"""""""""   /
  65. ---------------/
  66.  
  67. m  = monster
  68. p  = player start
  69. pe = player end
  70. "  = player footprints
  71. -> = direction of movement
  72.  
  73. Now, if the monster has a 'high' intelegence, it would see footprints going
  74. both left and right in the corridor at the end - how would it know which
  75. way to go?
  76.  
  77. However, a monster with a lower intelegence would get less footprints, and
  78. so would only see footprints on one side of the corridor - thus making it
  79. appear more intelegent than the first case.
  80.  
  81. > Of course, this still makes dumb monsters, very easy to shoot, so
  82. > they'll have to zig-zag to try to avoid your shooting, like in doom,
  83. > maybe we can think of differents moves, using differents formulas so
  84. > that all the monsters don't act the same way.
  85.  
  86. Sounds good...
  87.  
  88. > And, can't the monster find you by the noise you make ( in the Mexican
  89. > Food Inferno level...) ?
  90. > 
  91. > I though about it, and i think we can do it by generating footprints all
  92. > around the player (in every direction, in places that are step-able)
  93. > whenever he uses a noisy weapon. But, then we need
  94. > another structure for noise generated footprints (as when in chase mode we
  95. > need an ordered list of footprints), so the foot-made footprints are
  96. > checked first, and then the noise-prints second.
  97.  
  98. As of Doom version 1.666 (ie. later versions of Doom, and Doom 2) hearing
  99. was added to Doom. However, you cannot always hear - walls have a flag
  100. which indicates whether it is 'sound proof' or not. The method described
  101. above wouldn't work with sound-proof walls (I think)...
  102.  
  103. > And now for something completely different :
  104. > What is needed:
  105. > -thing-player collision
  106.  
  107. I guess this is not to difficult?
  108.  
  109. > -monster-sees-player function
  110.  
  111. ...but this? I guess this is a 3d problem... (I really ought to have paid
  112. more attention in those lectures...)
  113.  
  114. > -sector-thing-is-in-function
  115. > -speed optimization
  116. > 
  117. > This is a cut version. I want some feed back!
  118. > I've got some C code, too but it's not good enough at the moment.
  119.  
  120. Sounds like the basic idea is good, and could give nice 'following'
  121. monsters... Good work!
  122.  
  123. Anthony
  124.  
  125.  
  126. -- 
  127. -------------------------------------+------------------------------
  128. Anthony Jacques                      |  STOS Falcon Extension v1.2a
  129.                                      |  Generic STOS Fixer v0.98 
  130. mailto:jacquesa@cs.man.ac.uk         |  available from WWW pages
  131. http://www.cs.man.ac.uk/~jacquesa/   |  - UUEncoded on request.
  132. -------------------------------------+------------------------------
  133. NEWSFLASH: Falcon extn. 1.3 to be released within the next week...
  134.            Generic Fixer 1.0 also to be released within a week...
  135. -------------------------------------+------------------------------
  136.  
  137.